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Bei der Oberwachung einar Kraftwerksanlage sind eine 
Vielzahl von Oberwachungseinrichtungen mit Datenverar- 
beitungskomponenten vorgesehen, wobei die Datenverar- 
beitungskomponanten gemaS der der jaweiligen Komponen- 
ta zugeteilten technischen Aufgabe an verschiedenen Stel- 
len im Kreftwerk und entkoppalt voneinander instalJiert sind. 
Oia sichere und eindeutige Adressiarung dar in eincm 
solchen verteilten System vorhandenen Objekte vvird bisher 
dadurch gelost. daB sine ubergeordnete Instanz ein AdreS- 
register fuhrt. 

Zur Verbesserung einas solchen verteilten Systems ist 
erfindungsgemafi eine Infrastruktur (2) vorgesehen, bei der 
die Kommunikation in dam verteilten System (18} in einer 
Weise erfolgt, da& jedes Objekt ein internes Kennzeichen 
und einen Auspr9gungstyp umfaGt, anhand deren der Ob- 
jektmanager (20 bis 30) ermitteibar ist, der dieses Objekt 
verwaltet. Auf diese Weise ist ein ubergeordnetes AdreGre* 
gister nicht mehr srforderlich, denn die Objektmanager 
greifen die ihnen zugeordneten Daten selbsttatig auf. 
Oia Erfindung ist prinripiell bei alien Etnrichtungen zur 
Steuerung und Oberwachung komplexer technitcher Anla- 
gen eins tzbar. Sie ist ins bos ndere fur das Lertsystem v n 
Kraftwerksanlagen vorgesehen. 
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Die Erfindung bezieht sich auf eine Infrastruktur fur 
ein System von verteihen Objektmanager-Komponen- 
ten. insbesonriere fiir ein Leitsystem einer Kraftwerks- 
anlage, mit einer Anzahl von rechnergestutzten Objekt- 
manager- IComponenten. 

In einer Kraftwerksanlage sollen Uberwachungsein- 
richtungen die aktuellen Betriebszustande der Anlage 
erkennbar machen und Abweichungen von einem Soll- 
zustand melden. Dazu ist eine umfangreiche MeBwert- 
erfassung der Betriebszustande alier Anlagenteile, eine 
umfangreiche und der Komplexitat der Anlage gerecht- 
werdende MeBwertbewertung und eine unter hoher In- 
formationsverdichtung visualisiert aufbereitete Status- 
anzeige fur die Betriebszustande der Anlagenteile erfor- 

derlich. . . 

Diese vorstehend genannten Aufgabcn soil ein Leit- 
system erfullen. Bedingt durch die hohe Komplexitat 
solcher technischen Anlagen muB ein solches Leitsy- 
stem einfach und geradlinig struktunert sein. Dies be- 
deutet zum einen, daB Anlagenteile mittels des Leitsy- 
stems ubenvachbar und einstellbar sind und zum ande- 
ren, daB neue und/oder iiberarbeitete und geanderte 
Kontrolk Einstell- und/oder Auswerteoptionen in ein- 
facher Weise in das bestehende Leitsystem und seme 
Architekturintegrierbarsind. 

In der deutschen Patentanmeldung P 44 16 547.1 ist 
ein Leitsystem, insbesondere ein rechnergestiitztes Leit- 
system, vorgeschlagen, bei dem eine hohe Konfiguner- 
barkeit einer die MeBwerte be- und auswertenden Ebe- 
ne innerhalb des Leitsystems gegeben ist. Dies wird im 
einzelnen dadurch erreicht, daB die Leitebene modular 
aufgebaut ist und mehrere Funktionsbausteine umfaBt, 
die entsprechend ihrer jeweiiigen Funktion Eingangs- 
werte verarbeiten und unter Berucksichtigung einer 
Anzahl von zu losenden technischen Anwendungen un- 
tereinander verknupfbar sind. Aufgrund dieses modula- 
ren Aufbaus der Leitebene und ihrer Systeme sind eine 
nahezu beliebige Strukturierbarkeit und graphische 
Konfigurierbarkeit des Leitsystems in dieser Ebene ge- 
geben. Es konnen jederzeit Funktionsbausteine modifi- 
ziert, erganzt, weggenommen oder neu verknupft wer- 
den um eine zu losende technische Anwendung, wie 
z B* die ProzeBfuhrung bestimmter Anlagenteile, die 
ProzeBinformation, die KenngroBenberechnung oder 
die Bilanzierung.durchfuhren zu konnen. Die dabet ver- 
arbeiteten Eingangswerte konnen die unmittelbar von 
der Automatisierungsebene erhaltenen MeBwerte. be- 
reits mit einer Zugehorigkeitsfunktion bewertete MeB- 
werte, Zwischenresultate anderer Funktionsbausteine 
und liber cie Betriebsfahrungsebene vorgebbare pro- 
jektierbare Parameter sein. , 

Bei einem solchen meist rechnergestutzten Leitsy- 
stem ist es wunschenswert, wenn die Leitebene und die 
mit der Leitebene verbundenen Ebenen innerhalb einer 
gemeinsamen Systemumgebung, einer sogenannten In- 
frastruktur. gefuhrt sind. Hierzu ist es bekannt ein Be- 
triebssvstem. vorzugsweise ein handelsubhches Be- 
triebssvstem. wie z. B. UNIX oder OS 2. zu verwenden. 
das die Betriebsfahrungsebene. die Leitebene und die 
Automatisierungsebene sowie einen Datemransfer zwi- 
schen ciesen Ebenen unterhalt. Bei solchen Betnebssy- 
stemen ist es daruber hinaus wunschenswert. wenn die 
freie Verknupfbarkeit der in der Leitebene angeordne- 
ten Funktionsbausteine unterstutzt wird. und wenn erne 
weitgehende Unabhangigkeit des Leitsystems von der 
Innovationsgeschwindigkeit der Rechner- Hardware er- 



reicht wird. D 
Derzeit handelsubltche Betriebssysterne, wte z. B. 
UNIX oder OS 2, sind jedoch (iberfordert, wenn es im 
Rahmen einer Infrastruktur fiir ein System von verteil- 
ten Objektmanager-Komponenten darum geht, oei- 
spielsweise ein aus einer Anzahl von rechnergestutzten 
Objektmanager-Komponenten bestehendes verteiltes 
Svsiem hochzufahren. Eine nicht zufriedenstellende 
derzeitige Losung sieht hierzu einen ubergeordneten 
Rechner vor. der zu Beginn des Anlaufs die Informatio- 
nen uber die gesamte Configuration aller exjstierenden 
Objektmanager-Komponenten kennt. Bedingt durch 
die Komplexitat einer Kraftwerksaniage kommt es zu 
Storungen. wenn beispielsweise der ubergeordnete 
Rechner gestort isu oder wenn die Datenverbindungen 
zu diesem ubergeordneten Rechner gestort sind, oder 
wenn sich an der Gesamtkonfiguration noch kurzfnstig 
vor dem Anlaufen etwas geandert hat und diese Ande- 
rungen noch nicht zu Beginn des Anlaufs berucksichtigt 
worden sind. . 

Bedingt durch das hohe Datenaufkommen muB in ei- 
nem solchen System weiterhin die Adressierung der Da- 
ten, auch Objekte genannt, in besonders betnebssiche- 
rer Weise erfolgen. So ist es auch bisher ublich jedem 
Objekt eine eindeutige physikalische Adresse zuzuord- 
nen, an die dieses Objekt gesendet oder von der dieses 
Objekt versendet wird. Dies macht das Vorhandensem 
einer jederzeit aktuellen AdreBliste erforderhch. Insbe- 
sondere bei Umstrukturierungen, neuer Projektierung 
oder ahnlichen Aktionen, die die Adressierung von Ob- 
jekten moglicherweise weitreichend betreffen, ist das 
Fuhren einer solchen AdreBliste sehr aufwendig und mit 
Fehlerquellen behaftet. 

Der Erfindung liegt daher die Aufgabe zugrunde, eine 
Infrastruktur fur ein System von verteihen Objektma- 
nager-Komponenten anzugeben. die die vorstehend ge- 
nannte Adressierung von Objekten in emfacher und be- 
triebssicherer Weise gewahrleistet. 

Diese Aufgabe wird erfindungsgemaB dadurch gelost, 
daB eine Infrastruktur fiir ein System von verteihen 
Objektmanager-Komponenten mit einer Anzahl von 
rechnergestutzten Objektmanager-Komponenten die 
jeweils mindestens einen Objektmanager ausfuhren, 
vorgesehen ist, bei der die Kommunikation in einer 
Weise erfolgt, daB jedes Objekt ein internes Kennzei- 
chen und einen Auspragungstyp umfaBt, anhand deren 
der Objektmanager ermittelbar ist. der dieses Objekt 

Ve i5JJS5 wird unter einer Objektmanager-Komponen- 
te beispielsweise eine Workstation, ein Personal-Com- 
puter, ein Automatisierungssystem, wie z B. die Sie- 
mens Simatic S5 und S7, oder eine vergleichbare rech- 
nergestutzte Einrichtung verstanden. Unter einem Ob- 
jektmanager werden insbesondere bei einer Kraft- 
werksaniage die tolgenden Komponenten verstanden. 
Es sind dies das Man-Machine-Interface, das Archiv die 
Protokolliste, die Verarbeitungseinrichtung fur die Bau- 
steintechnik. eine Datenbank fur Beschreibungs- Sym- 
ptom- und Diagnosetexte und ein sogenannter Ab-Ke- 
prasentant der das Automatisierungssystem also die 
Schnittstelle zwischen KrahwerksprozeB und Daten- 
verarbeitung stutzt. 

Unter Objekten werden Daten jeglicher Art. wie i z. b. 
binare Signale, hexadezimale Signale. wie z. B. Real- 
Werte. fnfeger- Werte. Boolean-Werte oder Smng-Ket- 
ten. verstanden. Mit dem Auspragungstyp cin« ; Ob ek- 
tes ist beispielsweise zunachst gemcint. ob dieses Objekt 
d" verfahrenstechnischen Welt, der leittechnischen 
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Welt oder der anlagentechnischen Welt zuzuordnen ist. 
Weiter beinhaitet der Auspragungstyp eine KJassifizie- 
rung des Objektes nach seiner Aufgabenumgebung. 
Beispielsweise kann ein Objekt Alarm- oder Toleranz- 
meldungen. Hardware-Geratefehiern. Busfehlern oder 
Funktionsfehlern zugeordnei sein. Das interne Kennzei- 
chen ist nicht gleichbedeutend mit dem Begriff "Adres- 
se", weii das interne Kennzeichen kenerlei Ortsinforma- 
tion uber die Lage des Objektes besitzt. 

Auf diese Weise ist es moglich das Problem der 
Adressierung von Objekten von einer zentralen AdrcB- 
datei weg auf die einzelnen Objektmanager zu verla- 
gern. Die Serverschnittstellen der Objektmanager "hor- 
chen" in die Infrastruktur hinein und greifen die fur sie 
bestimmten Daten, die sie anhand des internen Kennzei- 
chens und des Auspragungstyps erkennen, heraus und 
bearbeiten diese. Damit sind die Objektmanager fur die 
Adressierung der ihnen zugeteilten Objekte selbst ver- 
antwortlich, was sich insbesondere auf die Projektie- 
rung und Umstrukturierung vorteilhaft auswirkt. 

In besonders vorteiihafter Weise ist die Infrastruktur 
dahingehend ausgestaltet. daB eine von einem Server 
gesteuerte diskontinuierliche Kommunikation vorgese- 
hen ist Alternativ dazu kann eine von einem Client 
gesteuerte kontinuierliche Kommunikation vorgesehen 
sein. 

Aufgrund der vorstehend genannten Eigenschaften 
eines Objekts beziigiich des internen Kennzeichens und 
des Auspragungstyps kann die Adressierung von Ob- 
jekten assoziativ erfolgen, d. h. es konnen ganze Objekt- 
klassen oder Gruppen anhand ihrer Eigenschaften aus- 
gewahk und beispielsweise bevorzugt bei der Daten- 
verarbeitung behandelt werden. 

Fur die Erledigung von Kommunikationsauftragen 
kann die Infrastruktur in besonders zweckmaBiger Wei- 
se dahingehend ausgestaltet sein, daB bei vorliegendem 
Kommunikationsauftrag eines Ciienten alle daran betei- 
ligten Server zur Datenausgabe aufgefordert sind. Vor- 
zugsweise kann hierbei eine Synchronisationsaufforde- 
rung an alle beteiligten Server ergehen. Fur die Entla- 
stung des Bussystems, Uber welches der Transfer von 
Objekten abgewickelt wird, ist es dann besonders vor- 
teilhaft, daB die Meldung des Vollzugs der Synchronisa- 
tion an den Client erst dann ergeht, wenn die Bereit- 
schaft zur Datenausgabe ailer verfugbaren Server vor- 
liegt. 

Weiter wird das Kornmunikationsaufkornmen bedeu- 
tend verringert, wenn eine Wiederanmeldung eines 
noch anstehenden Auftrages bei einem wiederverfug- 
bar gewordenen Server vorgesehen ist Es bedarf also 
hier keiner zusatzlichen Aufforderung curch den Client 
an einen solchen Server. Die Infrastruktur speichert ei- 
nen solchen noch anstehenden Auftrag zwischen und 
meldet diesen selbsttatig wieder an. 

Das Kornmunikationsaufkorr.men wird ferner da- 
durch in zweckmaBiger Weise begrer.zt, daB ein Kom- 
munikationsauftrag bezuglich seiner Parameterversor- 
gung uberpriifbar ist und der Auftrag bei fehlerhafter 
Parameterversorgung unter Angabe eines Fehlercodes 
ablehnbar ist. Au: diese Weise werden Server, die ver- 
geblich versuchen einen fehlerhaften Kommunikations- 
auftrag zu erledjgen, uberhaupt nicht biockiert, da ein 
solcher Auftrag erst gar nicht an den Server ergeht. 

Das Kommunikationsaufkommcn wird weiterhin be- 
sonders transparent, wenn die Infrastruktur in einer 
Weise ausgestaltet isu daB das dynamische Verhalten 
der Erledigung eines Komrr.unikationsauftrages nach- 
voilziehbar und verifizierbar ist. Dies wirkt sich zudem 
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vorteilhaft auf die Sicherheit des Datentransfers aus. 

AusfOhrungsbeispiele der Erfindung werden anhand 
einer Zeichnung naher erlautert. Dabei zeigen: 

Fig. 1 in schematischer Darstellung eine Infrastruktur 
5 fiir ein verteiltes System von Objektmanager-Kompo- 
nenten; 

Fig. 2 in schematischer Darsteliung einen in die Infra- 
struktur eingebetteten Objektmanager; 

Fig. 3 in schematischer Darsteliung den Cberwa- 
io chungsmechanismus der gemaB Fig. 1 dargestellten In- 
frastruktur; 

Fig. 4 in schematischer Darstellung den Oberwa- 
chungsmechanismus gemaB Fig. 3 bei dem Ausfall einer 
Objektmanager-Komponente; und 

■5 Fig. 5 in schematischer Darstellung den Oberwa- 
chungsmechanisrnus in der Infrastruktur gemaB den 
Fig. 3 und 4 in zwei Uberwachungsebenen. 

In den Fig. 1 bis^ 5 haben gleiche Teile die gleichen 
Bezugszeichen. 

20 In der in Fig. 1 gezeigten schematischen Darsteliung 
erkennt man die Infrastruktur 2 fur ein verteiltes System 
18 von Objektmanager-Komponenten 4 bis 16 als 
schraffiert unterlegte Flache. Das System 18 ist als Leit- 
system fur eine Kraitwerksanlage vorgesehen. Die Ob- 

25 jektmanager-Komponenten 4 bis 16 konnen Datenver- 
arbeitungsanlagen beliebiger Art, wie z. B. Groflrech- 
ner, Workstations. Personal-Computer und Host-Rech- 
ner jegiicher Art, sein. Auf den einzelnen Objektmana- 
ger-Komponenten 4 bis 16, von denen die Komponen- 

30 ten 10a und 10b sowie 12a und 12b redundant ausge- 
fiihrt sind, werden Objektmanager ausgefuhrt. 

Unter Objekten werden Daten jegiicher Art, wie z. B. 
binare Signale, hexadezimale Signale, wie z. B. Real- 
Werte, Integer- Werte. Boolean- Werte oder String-Ket- 

35 ten, versianden. Objektmanager sind also solche hard- 
waremaBig cder auch softwarema3ig realisierte Einhei- 
ten, die Objekte beliebiger Art verwahen. Objektmana- 
ger sind beispielsweise das Man-Machine-Interface 
(MMI) 20, das Archiv 22 zur Aufzeichnung der Ge- 

40 schichte des Kraftwerks (redundant ausgefuhrt als 22a 
und 22b). der Protokollverwalter 24 (ebenfalls redun- 
dant ausgefuhrt als 24a und 24b). der Verwalter 26 fur 
die Datenverarbeitung der in Bausteiniechnik vorgese- 
henen und hier nicht weiter dargestellten Leitebene.die 

as Datenbank 28 fur Beschreibungsdaten und der Repra- 
sentant 30 des Automatisierungssystems. Wie beispiels- 
weise anhand des Reprasentanten 30 des Automatisie- 
rungssystems gezeigt, kann ein Objektmanager auch auf 
mehreren Objektmanager-Komponenten, hier die 

50 Komponcnten 4 bis 8 und 16, gleichzeitig ausgefuhrt 
werden. 

Beim Anlauf des Systems 18 werden von einer dezen- 
tral angeordneten Initialisierungsdate: 32 die Anlaufda- 
ten in die Infrastruktur 2 eingegeben. Jeder der Objek:- 

55 manager-Komponenten 4 bis 16 hat einen Teil seiner 
zur Verf flgung stehenden Rechenleistung reserviert, um 
die Infrastruktur 2 in hardwaremaBig verschaiteter 
Form oder auch in softwaremaBig installierter Form zu 
betreiben. Die Anlaufdaten der Initialisierungsdatei 32 

ic enthaiten einen dezentraien Algorithmus. nach dem in 
eir.er ersien Phase des Ar.laufs die Objektmanager- 
Konponenten 4 bis 16 untereinander Kontakt aufneh- 
men unc der Infrastruktur 2 und damit aiien an der 
infrastruktur 2 beteiligten Komponenten 4 bis 16 ihre. 

0 - ( :o*ai :nstalliertcn Objektmanager 20 bis 30 bekannt. 
S.hti tiieser Kontaktaufnahme sind auf jeder Objekt* 
marker* Konponente 4 bis 16 alle aniaufenden Objekt- 
"•^r.avcr-^omponenten und alle don existierenden Ob- 
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jektmanager bekannt. 

In einer zweiten Phase werdcn mittcls der Infrastruk- 
tur 2 auf den Objektmanager-Komponenten 4 bis 16 die 
lokal installierten Objektmanager 20 bis 30 gestartet. 
Die Infrastruktur 2 wartet femer darauf, daB die Ob- 
jektmanager 20 bis 30 ihre Verfiigbarkeit als Server 
bekannt geben, und aktualisiert — auch wenn der Ober- 
wachungsmechanismus einen Abbruch eines Objektma- 
nagers erkanm hat — den neuen Zustand zusammen mit 
einer detaillierten Adressinformation auf alien Objekt- 
manager-Komponenten 4 bis 16. In einer dritten Phase 
werden die Objektmanager 20 und 26 auf den redundant 
vorliegenden Objektmanager-Komponenten 10a, 10b 
bzw. 12a, 12b gestartet. Dabei datet sich der jeweils 
fiihrende Redundanzpartner am alien Objektmanager- 
Komponenten 4 bis 16 gemeinsamen AnlaufprozeB auf 
und der oder die nichi fuhrenden Objektmanagerdaten 
sich beim jeweils fuhrenden Objektmanager auf. 

Die Infrastruktur 2 unterstutzt auch eine weitere An- 
taufsituation, bei der sich eine abgebrochene Objektma- 
nager- Komponente, beispielsweise die Komponente 6, 
in ein etablienes Teilsystem, bestehend aus den Kompo- 
nenten 4, 8 bis 16, wieder eingliedert. Die sich einglie- 
dernde Objektmanager-Komponente 6 stellt sich zu- 
nachst bei einer schon im Teilsystem etablierten Objekt- 
manager-Komponente, beispielsweise der Komponente 
8 f vor. indem die Objektmanager-Komponente 6 ihre 
lokal installierten Objektmanager, hier der Reprasen- 
tant 30 des Automatisierungssystems, mitteilt. Die loka- 
le Infrastruktur der Objektmanager-Komponente 8, 
dargestellt durch die schraffierte Flache innerhalb des 
Symbols fOr die Objektmanager-Komponente 8, macht 
die sich eingliedernde Objektmanager-Komponente 6 
im etablierten Teilsystem bekannt Die sich eingliedern- 
de Objektmanager-Komponente 6 erhalt von der Kom- 
ponente 8, bei der sie sich vorgestellt hat. die Informa- 
tionen iiber die Zustande und Adressen der Objektma- 
nager-Komponente 4, 8 bis 16 des etablierten Teilsy- 
stems und der darauf installierten Objektmanager. Auf 
diese Weise wird die Objektmanager-Komponente 6 in 
das etablierte Teilsystem eingegliedert ohne daB eine 
ubergeordnete Instanz, beispielsweise ein Leitrechner, 
vorgesehen ist, der die Konfiguration, Zustande und 
Adressen der ubrigen Objektmanager-Komponenten 
kennt. Diese Informationen sind vielmehr auf jeder Ob- 
jektmanager-Komponente 4 bis 16 im lokalen Teil der 
Infrastruktur 2 enthalten. so daB auch jede Anderung 
des Status einer Objektmanager-Komponente oder ei- 
nes Objektmanagers alien Objektmanager-Komponen- 
ten unmittelbar zuganglich ist. Dies wirkt sich besonders 
vorteilhaft auf die Serverfunktionen der Objektmana- 
ger und auf die Kenntnis deren Verfiigbarkeit im ge- 
samten System 18 aus. In beiden Anlaufsituationen star- 
let die Infrastruktur 2 die lokal installierten Objektma- 
nager, in dem sie deren Initialisierungsprozesse erzeugt. 
Objektmanager, die dem System 18 keine Serveriei- 
stung zur Verfiigung stellen, sind mit diesem Schntt 
sofort verfiigbar. 

Der Abbruch eines Objektmanagers 20 bis 30 wan- 
rend des Anlaufs wirk: sich abhangig vom Vorhanden- 
sein einer Redundanz auf den Zustand der entsprechen- 
den Objektmanager-Komponente 4 bis 16 aus: Bei vor- 
handener Redundanz werden die schon aktiven Objekt- 
manager beendet und die Objektmanager-Komponente 
wird als "abgebrochen" fur alle ubrigen Objektmanager- 
Komponenten zuganglich markiert. Ohne vorhandene 
Redundanz wird der Anlauf der Objektmanager-Kom- 
ponente fortgesctzt. Nur der vom Abbruch betroffenc 



Objektmanager wird als "abgebrochen" markiert. 

In Fig, 2 ist in schematischer Darstellung gezeigt. in 
welcher Weise ein Objektmanager, hier beispielsweise 
der Objektmanager 30. aufgebaut und in die Infrastruk- 
5 tur 2 eingebunden ist. Im vorliegenden Fall weist der 
Objektmanager 30 zwei Client-Schnittstellen 32, 34. ei- 
nen Init-Server 36, einen Server-Hauptteil 38, einen Ser- 
ver- Obertragungsteil 40 und einen Server 42 fur Projek- 
tierungsdienstc auf. 
10 Ober die Client-Schnittstellen 32. 34, die auch als 
Schnittstelle Client-lnfrastruktur 2 bezeichnet werden 
kann, werden Auftrage iiber die Infrastruktur 2 an Ser- 
ver ausgegeben, und es konnen Antworten vom Server 
iiber die Infrastruktur 2 in der Schnittstelle empfangen 
is werden. Hierbei kann die Schnittstelle als Mehrfach- 
wartestelle ausgef uhrt sein, so daB es moglich ist, auf die 
Ergebnisse verschiedener Auftrage unabhangig vonein- 
ander warten zu konnen, was sich besonders vorteilhaft 
auf die Synchronisation von Datenaustauschvorgangen 
20 auswirkt. 

Der Init-Server 36 wird beim Anlauf des Objektma- 
nagers 30 aufgerufen. Dieser Init-Server 36 startet und 
Oberwacht alle weiteren Prozesse, die auf dem Objekt- 
manager 30 ausgefuhrt werden. Der Init-Server 36 teilt 
25 alien ubrigen Prozessen daruber hinaus wichtige Konfi- 
gurations- und Adressinformationen mit. Falls der Ob- 
jektmanager 30 beendet werden soli, wird dies dem Init- 
Server 36 von der Infrastruktur 2 uber ein entsprechen- 
des Signal, beispielsweise ein UNIX-Signal, mitgeteilt. 
30 Das Beenden des Objektmanagers 30 wird der Infra- 
struktur 2 durch das Beenden des Init-Servers 36 mitge- 
teilt. 

Der Server-Hauptteil 38 stellt dem Server fur alle 
"Nutzfunktionen" des Objektmanagers 30 dar. Im Ser- 
35 ver-Hauptteil 38 ruft das Hauptprogramm nach der ei- 
genen Initialisierung durch den Init-Server 36 eine 
Oberwachungsfunktion auf. 

Diese Oberwachungsfunktion wartet uber die ge- 
samte Lebensdauer des Server-Hauptteils 38 auf Client- 
40 Auftrage und ruft entsprechend dieser Auftrage Server- 
Funktionen auf, d. h. der Server-Hauptteil 38 wartet in 
einer Wartestelle in der Infrastruktur 2 auf entsprechen- 
de Client-Auftrage. Diese Funktion ist daher eine Art 
vorgeschobener Horchposten aus dem Objektmanager 
4 5 30 heraus in die Infrastruktur 2. Erst wenn der Server- 
Hauptteil 38 beendet wird, verlaBt diese Funktion die 
■ Infrastruktur 2 und kehrt in das Hauptprogramm zu- 

riick- „ , 

Der Server-Cbertragungsteil 40 stellt einen in den 
«o ProzeB des Objektmanagers 30 eingebundenen Funk- 
tionssatz dar. uber den Server antworten (z. B. fur konti- 
nuierliche Auftrage) abgegeben werden. Der Server- 
Cbertragungsteil 40 ubertragt, falls sich em Client uber 
den Server-Hauptteil 38 angemeidet hat, die gewunsch- 
55 ten Ereignisse oder sonstige Ereignisse von kontinuierh- 
chen Auftragen. 

Der Server 42 fur Projektierungsdienste wartet nach 
seiner Aktivierung auf Projektierungsauftrage und legt 
die Projektierungsinformation in eine Objektmanager 
spezifische Datenbasis ab oder gibt sie an die innerhalb 
des Objektmanagers 30 betroffenen Prozesse welter. 

Die Infrastruktur 2 uberwacht und steuert die ge- 
samte Kommunikation in einer Weise. daB jedes Objekt 
em internes Kennzeichen und einen Auspragungstyp 
t5 umtalit. anhand deren der Objektmanager, beispielswei- 
se Objektmanager 30. ermittelbar ist, der dieses Objekt 
vcrwaltct. Hierbei wird unter einem Objekt jede Inf r- 
■natton \ers;anden, die in einer Datenverarbeitungsan- 
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lage zur Kommunikation von Prozessen ausgetauscht 
oder ubertragen wird Mit dem Auspragungstyp eines 
Objektes ist beispieisweise zunachst gemeint, ob dieses 
Objekt der verfahrcnstechnischen Welt, der leittechni- 
schen Welt oder der anlagentechnischen Welt zuzuord- 
nen isl Weiter beinhaitet der Auspragungstyp eine 
Klassifizierung des Objekts nach seiner Aurgabenumge- 
bung, beispieisweise kann ein Objekt .Alarm- oder Tole- 
ranzmeidungen, Hardware-Geratefehlern. Busfehlern 
oder Funktionsfehlern zugeordnet sein. Das interne 
Kennzeichen ist nicht gleichbedeutend mit dem Begriff 
"Adresse" weil das interne Kennzeichen keinerlei Orts- 
information Qber die Lage des Objektes besitzt. Dar- 
(iber hinaus kann dem internen Kennzeichen nicht ein- 
deutig eine Adresse zugeordnet werden. denn verschie- 
dene Daten eines Objekts konnen von verschiedenen 
Objektmanagern 20 bis 30 verwaltet werden, die unter 
Umstanden auf verschiedenen Objektmanager-Kompo- 
nemen 4 bis 16 angesiedeit sind. Auf diese Weise ist mit 
besonders vorteiihafter Wirkung eine Adressierung von 
Objekten anhand ihrer Eigenscharten. d h. eine associa- 
tive Adressierung, moglich. Hierdurch vereinfacht sich 
die Projektierung, weil ganze Objekt-Klassen ausge- 
wahlt werden konnen, ohne daB deren L.age im einzel- 
nen einem Objektmanager oder einer Objektmanager- 
Komponente bekannt sein miissen. So kann beispieis- 
weise von dem Objektmanager 4, dem Man-Machine- 
Interface, das Kommando abgesetzt werden "Suche 
Leittechnikfehler". Auf diese Weise sind in dem gesam- 
ten System 18 nur solche Objekte angesprochen, die 
gemaB ihres internen Kennzeichens und des Auspra- 
gungstyps in die Signalklasse "Leittechnikfehler" hinein- 
fallen. 

Die Kommunikation im System 18 kann zum einen 
eine von einem Server-gesteuerte diskontinuierliche 
Kommunikation und zum anceren eine von einem 
Client-gesteuerte. kontinuierliche Kommunikation sein. 
Bei der Server-gesteuerten Kommunikation muB der 
Client den Umfang der Ergebnisse nicht kennen. Teiler- 
gebnisse konnen ubertragen werden, wenn sie anfailen. 
Durch die Ciient-gesteuerte Kommunikation wird das 
gesamte Kommunikationsaufkommen im System 18 
verringert, weil keine Auftragswiederholungen notwen- 
dig sind. Die Infrastruktur 2 ist hierbei derart konzipiert. 
daB bei dem Vorliegen eines Kommunikationsauftrages 
eines Cliemen alle an diesem Auftrag beteiligten Server 
unmittelbar und nur einmaiig zur Datenausgabe aufge- 
fordert sind. Gleichzeitig kann mit einer solchen Auffor- 
derung eine Synchronisationsaufforderung an alle betei- 
lig-.en Server ergehen. Weiter kann in besonders zweck- 
ma3iger Weise die Meldung des Voilzugs der Synchro- 
nisation an den Client erst dann ergehen, wenn die Be- 
reitschaft zur Datenausgabe aller verfiigbaren Server 
vorliegt. so daB auch hier das Kommunikationsaufkom- 
men besonders gering ist, weil keine Nachfragen des 
Clients nach bestimmten Ergebnissen an einzelne Ser- 
ver ergehen. 

Eine weitere vorteilhafte Ausgestaltung der Infra- 
struktur 2 sieh; es von caB eine Wieceranmeldung eines 
noch anstehenden Auftrages eines Clienten bei einerr. 
wiederverfiigbar gewordenen Server vorgesehen ist. 
Die Infrastruk:ur 2 stellt also Ressourcen bereit, die alle 
im System 18 eingegangenen Auftrage erfaBt und spei- 
chert, falls ein Server zur Auftragserledigung nicht ver- 
fugbar is;. Da die Infrastruktur gleichzeitig jede Zu- 
standsanderung eines Servers bezuglich seiner Verfug- 
barkeit erfaBt. wird eir.e Auftragserledigung uhmittel- 
bar nach Wiederverfijgbarkeit ernes Servers "ange- 
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mahnf. 

Die Infrastruktur 2 ist weiter in der Lage einen Kom- 
munikationsauf;rag bezuglich der Parameterversor- 
gung zu prufen und den Auftrag bei fehlerhafter Para- 
5 meterversorgung unter Angabe eines Fehlercodes ab- 
zulehnen. Auf diese Weise konnen beispieisweise Fehler 
vermieden werden. wenn bei cer Suche nach einem 
Leittechnikfehler in der verfahrenstechnischen oder an- 
lagentechnischen Welt gesucht wird. Ein soicher Fehler 
:o ist nur in der ieittechnischen Wei- zu finden, d h. also bei 
den Datenquellen und Senken, die vom Auspragungstyp 
her mitcer FehlerkJasse Qbereinstimmen. 

Hierbei kann das dynaniische Verhalten der Erledi- 
gung eines Kommunikationsauftrages nachvolizichbar 

15 und verifizierbar sein. Eine solche Funktion kann bei- 
spieisweise iiber den Protokollverwalter 24 an die dem 
Man-Machine- Interface zugeordneten Drucker ausge- 
geben werden. Dies ist in cer Projektierungsphase be- 
sonders bedeutsam, wenn man nachvollziehen will, wel- 

20 che Daten woher geladen wurden, und in welcher Weise 
daraus Ergebnisse berechne: wurden. und wohin die 
Ergebnisse gesendet wurden. 

In Fig. 3 ist der Oberwachungsmechanismus der Ob- 
jektmanager-Komponenten 4 bis 16 in dem System 18 

25 dargestellt. Der Mechanismus wird anhand der Objekt- 
manager- Komponenten 4 bis 8 eriautert. Die Objekt- 
manager-Komponente 6 arbeitet bei der Oberwachung 
als Client fur die Objektmanager-Komponente 8 und als 
Server fur die Objektmanager-Komponeme 4. Die Ob- 

30 jektmanager-Komponenten 4 bis 16 sind zur Oberwa- 
chung ihres Zustandes in einem logischen Ring angeord- 
net, so daB keine ubergeordnete Oberwachungskompo- 
nente erforderlich ist. Die Oberwachung erfolgt nach 
dem Client-Server Prinzip. Die ais Client arbeitende 

35 Objektmanager-Komponente 6 sendet in definierten 
Zeitabst&nden ein Signai (Objekt) an die entsprechend 
als Server ausgebiidete Objektmanager-Komponente 8. 
Diese Komponente 8 sendet daraufhin ein "Lebenszci- 
chen" an die Komponente 6. In gleicher Weise erhalt die 

40 Komponente 6 von der Komponente 4 in definierten 
Zeitabstanden eine Aufforderung, ein 'Lebenszeichen" 
zu sender.. Zur Serversuche lauft auf alien Objektmana- 
ger-Komponenten 4 bis 16 der gleiche Algorithmus ab. 
beispieisweise konnen die Objektmanager-Komponen- 

45 ten 4 bis 16 ihren Cberwacher und den zu Uberwachen- 
den anhand der alphabetischen Reihenfolge ihrer Be- 
nennung ermitteln. 

In Fig. 4 ist eine gegenuber Fig. 3 geringfugig modifi- 
ziene Konfiguration des Systems 18 dargestellt. Hier 

5C sind die Objektmanager-Komponenten 6 und 10a aus- 
gefallen. Der Server der ausgefallenen Objektmanager- 
Komponente 6 kenni cie Konfiguration dieser Kompo- 
nente unc teilt uber die Infrastruktur 2 den verbieiben- 
den Objektmanager-Komponenten alle mit der Objekt- 

55 manager-Komponente ausgefallenen Objektmanager 
mit Dies is; im vorliegenden Fall der au: der Objektma- 
nager-Komponente 6 curchgefuhrte Objektmanager 
30. Gerr.ii3 der vorgegebenen Algorithmus hat die Ob- 
jektmanager-Komponente 4 nun nicht die Objcktmana- 

£0 ger-Komponente 6 als Server, sondern die Objektmana- 
ger-Komponente 8. so daB die im verbleibenden System 
aktiven Objektmanager-Komponenten 4, 8 bis 16 wie- 
der einen logischen Cberwachungsring bilden. Will sich 
die Objektmanager-Komponente 6 wieder in das Sy- 

cs stem eingliedern. meldet sie sich bei der Objektmana- 
ger-Komponente 8 an. gibt ihre lokal instailierten Ob- 
jektmanager. hier der Objektmanager 30, bekannt und 
erfahrt von der Objekimanager-Komponente 8 die 
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[Configuration und Zustande aller ubrigen Objektmana- 
ger-Komponenten. Dies ist durch die gestrichelten Pfei- 
le 44 symbolisiert 

Ein weiterer Spezialfall ist fur die Objektmanager- 
Komponenten 10a und 10b dargestellt. Diese Kompo- 
nente ist redundant ausgefuhrt. Im gezeigten Fall ist die 
Komponente 10a ausgefallen. Der Server dieser Kom- 
ponente 10a kennt die {Configuration dieser Komponen- 
te und die auf dieser Komponente lokal installierten 
Objektmanager, hier das Man-Machine-Interface 20, 
und teik den ubrigen Objektmanager-Komponenten, 
die mit der Objektmanager-Komponente ausgefallenen 
Objektmanager mit. Hierbei ist es die Infrastruktur 2, 
die ein fur alle Objektmanager-Komponenten zugangli- 
ches Ereignis generiert, das insbesondere den verblei- 
benden Komponenten mitteilt, ob eine Objektmanager- 
Komponente "prozeBfiihrend" oder "nicht-prozeBfuh- 
rend" ist bei redundanter Ausfuhrung der jeweiligen 
Komponente. 

Nach dem Ausfall der Komponente 10a erfolgt der 
Zustandsubergang der Objektmanager-Komponente 
von "nicht-prozeBfuhrend" nach "prozeBfuhrend" der 
Komponente 10b selbsttatig. Hierbei kann es wciter 
vorgesehen sein, daB zum Aufdaten von Objektmana- 
gern auf wiederanlaufenden redundanten Objektmana- 
ger-Komponenten der prozeBfiihrende Server auf Auf- 
trag ein konsistentes Abbild seiner ProzeBdaten erstellt 
und zum aufrufenden Client, hier der Server der ausge- 
fallenen Objektmanager-Komponente 10a, ubertragt. 
Urn den Redundanz-Zustand einer Objektmanager- 
Komponente fur die Ubrigen Komponenten zuganglich 
zu machen. ist es vorgesehen, daB jede Objektmanager- 
Komponente 4 bis 16 oder jeder Objektmanager in dem 
entsprechenden Server- Hauptteil 38 eine Schnittstelle 
aufweist, die eine Anderung des Redundanz-Zustandes 
der jeweils anderen Objektmanager-Komponenten 
oder Objektmanager erfaBt 

Insbesondere fiir die Handhabung einer sicheren Da- 
teniibertragung von redundant ausgefiihrten Objektma- 
nager-Komponenten ist die Infrastruktur 2 derart aus- 
gestaltet, daB die Obermittlung eines datenlesenden 
Auftrages selbsttatig an den prozeBfiihrenden Server 
erfolgt. Hierzu dient beispielsweise der Eintrag in der 
vorstehend genannten Schnittstelle bezuglich des Zu- 
stands einer Objektmanager-Komponente oder eines 
Objektmanagers. Gleichzeitig sorgt die Infrastruktur 2 
dafiir, daB die Cbermittlung eines datenschreibenden 
Auftrages an alle zueinander redundanten Objektmana- 
ger-Komponenten oder Objektmanager erfolgt, so daB 
der nicht prozeBfiihrende Teil jederzeit in der Lage ist, 
die ProzeBfiihrung zu ubernehmen. 

Auch der logische Ring zur Oberwachung der Ob- 
jektmanager-Komponenten 4 bis 16 schlieBt sich bei 
dem Ausfail der Objektmanager-Komponente 10a 
selbsttatig, weil die Objektmanager-Komponenten 4 
und 12a, 12b automatisch auf die redundante Objektma- 
nager-Komponente 10b umschalten, die ihren Zustand 
von "nicht-prozeBfuhrend" nach "prozeBfuhrend M gean- 
dert hat, wie dies die Pfeile 46, 48 symboiisieren. 

In Fig. 5 ist nochmals der logische Ring zur Oberwa- 
chung der Objektmanager-Komponenten 4 bis 16 sche- 
matisch dargestellt. Hierbei soil deutlich gemacht wer- 
den, daB die Oberwachung in zwei Ob rwachungsebe- 
nen erfolgt. In der ersten Uberwachungsebene uberwa- 
chen sich die Objektmanager-Komponenten 4 bis 16 
selbsttatig im gemaB Fig. 3 beschrieben n Ring. Dies ist 
in Fig. 5 durch die Pfcilverbindungen von Objektmana- 
ger-Komponente zu Objektmanager-Komponente 



symbolisiert 

An der hier ausgewahlten Objektmanager-Kompo- 
nente 14 ist die zweite Oberwachungsebene schema- 
tisch dargestellt. Innerhalb einer Objektmanager-Kom- 

5 ponente werden zyklisch wiederkehrend die Zustande 
der einzelnen lokal installierten Objektmanager, hier 
der redundant ausgefUhne Protokollverwalter 24a, 24b 
und die Datenbank 28 fur Beschreibungsdaten, uber- 
wacht Auf diese Weise ist eine Entkopplung der Ober- 

I0 wachungsprozesse fur Objektmanager-Komponenten 
und Objektmanager erreicht, so daB beispielsweise nach 
dem Ausfall eines einzelnen Objektmanagers nicht die 
gesamte Objektmanager-Komponente als ausgefallen 
gemeldet werden muB. 
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Patentanspruche 

1. Infrastruktur (2) fiir ein System (18) von verteil- 
ten Objektmanager-Komponenten (4 bis 16), insbe- 
sondere fiir ein Leitsystem einer Kraftwerksanlage, 
mit einer Anzahl von Objektmanager-Komponen- 
ten (4 bis 16), die jeweils mindestens einen Objekt- 
manager (20 bis 30) ausfuhren, wobei die Kornmu- 
nikation in einer Weise erfolgt, daB jedes Objekt 
ein internes Kennzeichen und einen Auspragungs- 
typ umfaBt, anhand deren der Objektmanager (20 
bis 30) ermittelbar ist, der dieses Objekt verwaitet. 

2. infrastruktur (2) nach Anspruch 1, dadurch ge- 
kennzeichnet, daB eine von einem Server gesteuer- 
te, diskontinuierliche Kommunikation vorgesehen 
ist 

3. Infrastruktur (2) nach Anspruch 1, dadurch ge- 
kennzeichnet, daB eine von einem Client gesteuer- 
te, kontinuierliche Kommunikation vorgesehen ist. 

4. Infrastruktur (2) nach einem der Anspruche 1 bis 

3, dadurch gekennzeichnet daB eine assoziative 
Adressierung vorgesehen ist. 

5. Infrastruktur (2) nach einem der Anspruche \ bis 

4, dadurch gekennzeichnet, daB bei vorliegendem 
Kommunikationsauftrag eines Clienten alle daran 
beteiligten Server zur Datenausgabe aufgefordert 
sind. 

6. Infrastruktur (2) nach Anspruch 5, dadurch ge- 
kennzeichnet, daB eine Synchronisationsaufforde- 
rung an alle beteiligten Server ergeht. 

7. Infrastruktur (2) nach Anspruch 6, dadurch ge- 
kennzeichnet, daB die Meldung des Vollzugs der 
Synchronisation an den Client erst dann ergeht, 
wenn die Bereitschaft zur Datenausgabe aller ver- 
fugbaren Server vorliegt 

8. Infrastruktur (2) nach einem der Anspruche 5 bis 

7, dadurch gekennzeichnet. daB eine Wiederanmel- 
dung eines noch anstehenden Auftrages bei einem 
wiederverfugbar gewordenen Servers vorgesehen 
ist 

9. Infrastruktur (2) nach einem der Anspruche 1 bis 

8. dadurch gekennzeichnet, daB ein Kommunika- 
tionsauftrag bezuglich seiner Parameterversor- 
gung uberpriifbar ist und der Auftrag bei fehlerhaf- 
ter Parameterversorgung unter Angabe eines Feh- 
lercodes abiehnbar ist. 

10. Infrastruktur (2) nach Anspruch 9, dadurch ge- 
kennzeichnet daB das dynamische Verhalten der 
Erledigung eines Kommunikationsauftrages nach- 
vollziehbar und verifizierbar ist. 



Hierzu 5 Seite(n) Zeichnungen 



- Leerseite - 



TH/S PAGE BLANK (uscro) 




602 050/177 



ZEICHNUNGEN SEFTE 2 



Nummer: 
Int. Cl. ft : 

Offenlegungstag: 



DE 185 20746 A1 
Q06B IS/00 

12. Dezember 1996 



/ 




/ 






/ 



36 



J 



32 
_L 



l 38 
□ 



tO J 3*. L tt 
1 



30 




2, 



FIG 2 



602 050/177 



ZEICHNUNGEN SEITE 3 mmer: DE 195 20745 A1 

Int. CI. 6 : G06B 15/00 

Offeniegungstag: 12. Dezember 1996 




602 050/177 




602 050/177 



ZEICHNUNGEN SE1TE 5 



mmer: DE 195 20 746 A1 

Int. CI. 6 : Q06B 16/00 

Offenlegungstag: 12. Dezember 1996 




602 050/177 



1/9/1 

DIALOG (R) File 351:Derwent WPI 

(c) 2002 Derwent Info Ltd. All rts . reserv. 



011057192 **Image available** 

WPI Acc No: 1997-035117/ 199704 

XRPX Acc No: N97-029501 

Infrastructure for distributed object manager component control system - 
has object managers of respective object manager components supplied with 
object internal identification and maker type for management development 

Patent Assignee: SIEMENS AG (SIEI ) 

Inventor: FRITZ P; GLASER M; WALZ H 

Number of Countries: 001 Number of Patents: 002 

Patent Family: 

Patent No Kind Date Applicat. No Kind Date Week 

DE 19520745 Al 19961212 DE1020745 A 19950607 199704 B 

DE 19520745 C2 19990930 DE 1020745 A 19950607 199944 

Priority Applications (No Type Date) : DE 1020745 A 19950607 
Patent Details: 

Patent No Kind Lan Pg Main IPC Filing Notes 
DE 19520745 Al 11 G05B-015/00 
DE 19520745 C2 G05B-015/00 



Abstract (Basic) : DE 19520745 A 

The infrastructure (2) has a number of distributed object manager 
components (4-16), each with at least one object manager (30). Each 
object is assigned an internal identification and a make type, used by 
the object manager (20-30) in the object management. 

Pref . a discontinuous communication system controlled by a server 
is used for communication within the distributed control system having 
a number of monitoring devices and associated processing units at 
distributed monitoring points. 

USE/ADVANTAGE - For complex control of power generation plant. 
Eliminates need for address register. 

Dwg.1/5 

Title Terms: DISTRIBUTE; OBJECT; MANAGE; COMPONENT; CONTROL; SYSTEM; OBJECT 
; RESPECTIVE; OBJECT; MANAGE; COMPONENT; SUPPLY; OBJECT; INTERNAL; 
IDENTIFY; MAKER; TYPE; MANAGEMENT; DEVELOP 

Derwent Class: T01; T06; X12 

International Patent Class (Main) : G05B-015/00 

International Patent Class (Additional) : G05B-023/00; G06F-019/00; 

H02J-013/00 
File Segment: EPI 

Manual Codes (EPI/S-X) : T01-F07; T01-J07B; T01-M02A; X12-H03 



THIS PAGE BLANK (uspto, 



